Connectivity Software User's Guide and Reference
Multithreading and Synchronization
In this article, when we refer to a communication component, we mean
The communication components and all their related helper objects are thread-safe.
In .NET, if you are hooking to the event notifications provided by a communication component, or processing these notifications in your callback methods, make sure that you understand how the component generates these events and what threading issues it may involve. This is how it works:
The communication component has a SynchronizationContext property. This property can either be set to a null reference, or to an instance of System.Threading.SynchronizationContext class. When the SynchronizationContext is set to a null reference, The communication component calls any event handlers or callback methods on its own internal thread, which is possibly different from any threads that you have in your application. When the SynchronizationContext is set to a concrete instance, the synchronization model implemented by this object is used. The communication component then typically uses the Post method of this synchronization context to invoke event handlers in your application.
When the communication component is initially created, it attempts to obtain the synchronization context from the current thread (the thread that is executing the constructor). As a result, if the thread constructing the communication component has a synchronization context associated with it, it will become the value of the SynchronizationContext property. Otherwise, the SynchronizationContext property will be set to a null reference. This way, the synchronization context propagates from the constructing thread.
Access to Windows Forms controls or WPF controls is not inherently thread safe. If you have two or more threads manipulating the state of a control, it is possible to force the control into an inconsistent state. Other thread-related bugs are also possible, such as race conditions and deadlocks. It is important to make sure that access to your controls is performed in a thread-safe way. Thanks to the mechanism described above, this is done automatically for you, provided that the constructor of the communication component is called on the form’s main thread, as is the case if you place the communication component on the form’s design surface in Visual Studio. This works because by default, Windows Forms set the synchronization context of the form’s main thread to a properly initialized instance of System.Windows.Forms.WindowsFormsSynchronizationContext object.
Similarly, Windows Presentation Foundation (WPF) applications use System.Windows.Threading.DispatcherSynchronizationContext to achieve the same thing.
If your application is not based on the above frameworks, or is using them in an unusual way, you may have to take care of the synchronization issues related to event notification yourself, either by directly coding the synchronization mechanism, or by implementing and using a class derived from System.Threading.SynchronizationContext.
Objects in the Forms namespaces follow the general Windows Forms rules and conventions, meaning that any public static (Shared in Visual Basic) type members are thread-safe. Any instance members are not guaranteed to be thread safe.
In COM, if you are hooking to the event notifications provided by a communication component, make sure that you understand how the component generates these events and what threading issues it may involve. The event notifications generated by the communication component originate from a thread that may be (and generally is) different from the thread that you used to create an instance of the object or call its methods. The code in your event handler must be prepared to deal with it.
A typical issue that arises is that access to Windows controls is not inherently thread-safe, and should be done from a dedicated thread only. It is important to make sure that access to your controls is performed in a thread-safe way. This typically involves setting up some communication mechanism between the event handler code, and a thread dedicated to handling the user interface of your application.
Sparkplug is a trademark of Eclipse Foundation, Inc. "MQTT" is a trademark of the OASIS Open standards consortium. Other related terms are trademarks of their respective owners. Any use of these terms on this site is for descriptive purposes only and does not imply any sponsorship, endorsement or affiliation.